home *** CD-ROM | disk | FTP | other *** search
/ Delphi Developer's Kit 1996 / Delphi Developer's Kit 1996.iso / power / dbflit16 / readme.txt < prev   
Encoding:
Text File  |  1995-12-22  |  8.3 KB  |  176 lines
  1.                TUZFILTER V. 1.06 - free filtering on any DataSource 
  2.                ====================================================
  3.  
  4.  
  5. Hi, out there in the wilderness. Here may come a the solution for many of your
  6. problems, related to filtering and indexing under DELPHI.
  7.  
  8. This little component implements a BDE-level filter, based on a callback into
  9. your form's/unit's code, much like those QSort.-callback were.
  10.  
  11. The callback function does all the filtering stuff, ie. detemines, whether the
  12. current record in scope is to be included or excluded, INDEPENDENTly of any
  13. index-settings, data-links, 1:m table links or whatever and LIVE.
  14.  
  15. Installation:   after unpacking the ZIP-file, you'll find following files:
  16.  
  17.    -> FILTDEMO.*     a little demo-application
  18.    -> FLTDEMO1.*     unit for FILTDEMO
  19.  
  20.    -> DBFILTUZ.INT   documentation (installation AND HOW TO USE)
  21.    -> DBFILTUZ.DCU   TUZFilter VCL-component (see installation section in
  22.                      DBFILTUZ.INT)
  23.    -> DBFILTUZ.DCR   resource-file for DBFILTUZ.DCU
  24.  
  25.  
  26. RUNNNING the example in FILTDEMO:
  27.  
  28.    following prerequisites have to be fullfilled to run FILTDEMO "out of the
  29.    box":
  30.  
  31.    ->    A valid DBDEMOS-alias in you BDE-configuration (CUSTOMER.DB and
  32.          ORDERS.DB will be accessed) must exist.
  33.    ->    DBFILTUZ.DCU m,ust be installed to your COMPLIB.DCL (see installation
  34.          section "how to install" in DBFILTUZ.INT)
  35.  
  36.  
  37. FREEWARE:   This component is FREEWARE according to the terms in DISCLAIMER'S
  38.             NOTE in DBFILTUZ.INT.
  39.             Source can be obtained from author (see contact address at end of
  40.             this file).
  41.  
  42.  
  43. ADDITIONAL INFO, READ CAREFULLY:
  44. ================================
  45.  
  46.    I don't know, whether to state this as a "known bug" or not, but at least
  47.    the following hint might be very helpful, bioth for security of code and
  48.    for speed:
  49.  
  50.    DON'T CODE a "Application.ProcessMessages" line into your filterevent-handler
  51.  
  52.    Doing so, might confuse BDE which callback-events are "still to be processed"
  53.    and which alredy are processed, leading into recursive calls of the filter-
  54.    event handler until memory is low and BDE will GPF (IDAPI01.DLL 0003:xxxx or
  55.    0001:xxxx).
  56.    This GPFs might freeze WIN as well as throw backl the hard way onto DOS-prompt,
  57.    leaving tables open, records locked and so on.
  58.  
  59.  
  60.  
  61.  
  62. HISTORY of changes:
  63. ===================
  64. VERSION 1.06:  BUG-Fix: unfortunatly, I had a bug built into TUZFilter, sorry
  65.                for that.
  66.                Funny, but true, the bug resulted from an additional security-
  67.                byte for the callback's dataset-record.
  68.                However, I fixed that bug (cause an GPF at 0001:18A5 in your
  69.                app).
  70.  
  71. VERSION 1.05:  hmmm, should I call this one a BUG-fix ? Well decide youself,
  72.                here is what's happening why and how I worked around.
  73.                Although V 1.04 worked very well and properly when PDX-tables
  74.                were used, two users reported, that, when issuing a .LAST on a
  75.                filtered dBASE-table (i.e. by a TDBNavigator-control), their
  76.                programs threw an "at end of table exception", though neither
  77.                the EOF-condition really was true, nor any erratic behavior
  78.                took place, just that ugly nasty exception-box in front of your
  79.                users'r eyes ....
  80.                Richard Lebeda (tanks to him) provided me with a minimal sample,
  81.                to reproduce that "feature", which _only_ occurs, if a BDE-
  82.                callback filter ion dBASE-tables is aborted (which is done
  83.                behind the screens, to get .FIRST/.LAST worling) and the table
  84.                was set to it's last record. This IMHO is a bug in
  85.                IDDBAS01.DLL, because aborting a callback-filter under no
  86.                circumstances should result in a EOF or BOF condition and for
  87.                sure it does not, when IDPDX01.DLL is used for PDX-tables.
  88.  
  89.                Well I can't rewrite the IDDBAS01.DLL but I found a workaround,
  90.                which at least hides those ugly exceptions before the
  91.                applications user's eyes.
  92.                That workaround is done by temporarily catching exceptions,
  93.                when a filter for dBASE-tables is up to be aborted (don't be
  94.                concerned, the original exception-handler is restored immediatly
  95.                after that EOF-exception has been catched).
  96.                This avoids the EOF-exception trap, when your program is
  97.                running in "real live", but it can't avoid that exception,
  98.                under following circumstances:
  99.  
  100.                -> dBASE table is set to last record
  101.                -> filter is active
  102.                -> OPTIONS | ENVIRNMENNT "stop on exceptions" is set TRUE
  103.                -> DELPHI's debugger is running
  104.  
  105.                for DELPHI's own exception-catcher (invooked by that "stop on
  106.                exceptions" switch) will trap the exception, _before_ it
  107.                reaches the "exception-killer" in TUZFilter. So, while
  108.                designing/developing your program and matching the above
  109.                conditions, yout might have to resume your program by F9/run-
  110.                btn, when this exception will occur.
  111.  
  112.                Sorry, for beeing unable to provide you with a better solution,
  113.                but, if I would prevent from aborting the filter when a .LAST
  114.                move on dBASE-tables is issued, you won't see the last record,
  115.                and I think a some of those nasty exception during development-
  116.                cycleboxes are much better, than embezzling the last record.
  117.  
  118.                
  119.                
  120. VERSION 1.04:     BUG-fixes:
  121.                   -> .LAST-method resulted in an empty result set/first record
  122.                   -> adding a new record might result in an empty result set
  123.  
  124.    thanks to Frank BĪ£urle, who reported the bug on the .LAST-method on a
  125.    dataset. This bug occurred when acting as follows:
  126.  
  127.       -> either use the mouse to drag the vertical slider thumb to it's lower
  128.          end position (will result in an .LAST command on the dataset)
  129.       -> or issue the .LAST command by keybord with crtl-end
  130.  
  131.    in both situations, V 1.03 returned an empty result set. This bug has been
  132.    fixed and in addition some similar or related bugs has been fixed too:
  133.  
  134.       -> crtl-end or dragging the vert-thumb to the lower end on a DETAIL-
  135.          table resulted in moving to the first instead of the last record in
  136.          detail table (fixed)
  137.       -> adding/inserting a new rceord into a filtered dataset may too have
  138.          resulted in an empty resuult set under V 1.03 (fixed too, now works
  139.          as expected)
  140.          
  141.  
  142. VERSION 1.03:     BUG-fix, speed-improvement and initial default-setting
  143.  
  144.    bug-fix:   When using two master-datail linked tables like in the demo-form, and
  145.    "quick-scrolling" thru the nmaster-tables by mouse (holding the down-arrow of
  146.    the grid pressed), a "not enough memory-error" occurred, this should be fixed
  147.    now (tnx to Peter Gentes, pointing me in rioght direction).
  148.    Additionally, a similar bug lead to a GPF in IDAPI01.DLL, when a master-
  149.    record with _no_ detail-recs was reached and the two tables additionally
  150.    were liked by PdX' referential integrity, should be fixed too.
  151.  
  152.    speed-imporvement:   the detail-table isn't rebuild after every single
  153.    record-skip in the master-table which (at least, when scrolling by
  154.    keyboard) should improve scrolling speed.
  155.  
  156.    initial default setting:   I just added a default setting for all
  157.    TUZFilter-properties when you draw a new component on your form.
  158.  
  159.  
  160. VERSION 1.02:     correction in FLTDEMO1.PAS uses-clause
  161.  
  162.    so sorry, V 1.01 did include a typo. The uses-clause in FLTDEMO1 referenced
  163.    a component DBFILTER (which was the original name of DBFILTUZ suring
  164.    develpment, but has changed due to the fact, that I found another component
  165.    already using that name). Unfortunatly, I just added the DBFiltUZ
  166.    forgetting to delete the now obsolete old reference.
  167.    In V 1.02 this has been changed, so compiles will no more break down with a
  168.    "component not found" error for the obsolete refernce. That's the only
  169.    change for V 1.02.
  170.  
  171.  
  172. may the gods of the olymp smile on you ...
  173.  
  174. bye UZ/2       CIS: 100271,313
  175.  
  176.